home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000045_csj@iesd.auc.dk _Sun Mar 21 16:04:47 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  3KB
  1. Received: from iesd.auc.dk by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA21740; Sun, 21 Mar 1993 08:04:48 MST
  3. Received: from yellow.iesd.auc.dk by iesd.auc.dk with SMTP id AA26193
  4.   (5.65c8/IDA-1.5/MD for <tsql@cs.arizona.edu>); Sun, 21 Mar 1993 16:04:47 +0100
  5. Date: Sun, 21 Mar 1993 16:04:47 +0100
  6. From: "Christian S. Jensen" <csj@iesd.auc.dk>
  7. Message-Id: <199303211504.AA26193@iesd.auc.dk>
  8. To: tsql@cs.arizona.edu
  9. Subject: Benchmark schema
  10.  
  11.  
  12.                  The TSQL Benchmark Draft - TASK I
  13.                  *********************************
  14.  
  15. Below, I briefly comment on the topics that have been brought up so
  16. far. I a few days, I will attempt to update the benchmark document to
  17. reflect the recent discussions while maintaining consistency. I will
  18. also include a straw proposal for data for the benchmark schema.
  19.  
  20. 1. Scope of the initial version of the benchmark.
  21.  
  22. Two extensions of the scope have been suggested, namely
  23.  
  24.        (a) it should be possible to use the same relation more than
  25.        once in each query
  26.        (b) queries involving aggregation facilities should be included
  27.  
  28. It has also been argued that these extensions should wait until the
  29. next version. This is the current, unchallenged proposal.
  30.  
  31. Aggregation is very important, but is also a substantial extension.
  32. For that reason, I would like to postpone (b) to the next version.
  33.  
  34. I would like to propose another extension:
  35.  
  36.     (c) it should be possible to ask queries involving valid time
  37.         and user-defined time
  38.  
  39. Queries like "Who made more than 30K before turning 25" are very
  40. natural, and a well-designed query language should be able to express
  41. such queries conveniently.
  42.  
  43. The current schema has no user-defined time attributes. Such
  44. attributes are needed in order to support (c). The most obvious
  45. extension appears to be to add birth day as an attribute in the Emp
  46. schema.
  47.  
  48. If (a) and (b) are to be postponed to the next version, it is
  49. reasonable to also postpone (c). I propose that the introduction is
  50. divided into two. One part will describe the goal of the benchmark.
  51. The second part will describe the scope of the current version.
  52. Limitations (a) - (c) should be indicted clearly. In addition, the
  53. second par will reflect our discussions about how the scope should be
  54. extended in the next version.
  55.  
  56. 3. Additional attributes.
  57.  
  58. The inclusion of additional attributes has been argued.
  59.  
  60. Support for (c) above motivates the inclusion of a user-defined time
  61. attribute (birth day, to be added to Emp). This addition can wait
  62. until (c) is included.
  63.  
  64. Inclusion of time-invariant (same as "non-temporal") attributes has
  65. been proposed. It is my feeling that the motivation for this is to
  66. obtain a schema better suited for queries involving aggregates (?). A
  67. attribute like "gender" should then be added when aggregation is
  68. introduced. I propose that this addition is postponed until (b) is
  69. included.
  70.  
  71. Inclusion of a multivalued dependency which is not a functional
  72. dependency has been proposed, possibly in a future version. This may
  73. be accomplished by adding a "skills" attribute to the Emp schema. I
  74. propose that we maintain a list of useful extensions like this one.
  75.  
  76. Best regards,
  77. Christian S. Jensen
  78. Aalborg University